Usage characteristics in the Internet have significantly changed over the years. The Internet has been designed for point-to-point connections, such as downloading content from a particular server, accessing an email server or, lately, having a voice over IP conversation. For these applications, having exactly the right endpoints in a connection is a requirement. Routing of messages between the endpoints is typically based on Internet Protocol (IP) addresses, which are also often used to identify the node, for instance directly or via a Domain Name System (DNS) translation.
Increasing mobility of users along with the trend to multi-homing and multi-access have soon made it clear that the semantic overloading of the IP address as both network locator and node identifier is problematic. Proposals like the Host Identity Protocol, HIP, (compare R. Moskowitz and P. Nikander, “Host Identity Protocol Architecture”, RFC 4423) or the Internet Indirection Architecture, i3, (compare Ion Stoica, Daniel Adkins, Shelley Zhuang, Scott Shenker, Sonesh Surana, “Internet Indirection Infrastructure”, SIGCOMM 2002) have addressed this by decoupling the identity of the node from its location in the network. The identity of the node is expressed by an identifier that can eventually be re-solved into the network address a node is currently reachable at. Additionally, host identities can have cryptographic properties, such as the 128 bit Host Identity Tag in HIP which is a hash over the public part of an asymmetric key pair also used for authentication and encryption.
Today, one can observe a new paradigm shift: The trend to so-called dissemination traffic, i.e. operations such as retrieving a website or downloading a video. In contrast to the classical point-to-point connections, where the source and the destination addresses are essential parts of the communication, dissemination traffic has different characteristics. In most cases it is not relevant who delivers the desired content, as long as it can be assured that it is the correct content.
A common way of addressing online content is the Uniform Resource Identifier (URI) which is often semantically overloaded, similar to the IP address that was to serve both as a network locator and node identifier. In many cases, the URI a user enters into his browser (for instance http://www.4ward-project.eu/index.html) is used as an opaque identifier for a piece of information (in this case the 4WARD homepage). The URI is resolved into the actual host serving the request by mechanisms like DNS round-robin schemes for load balancing or more sophisticated schemes as in Content Distribution Net-works like Akamai (compare J. Pan, Y. T. Hou, and B. Li, “An overview of DNS-based server selections in content distribution networks”, Computer Networks, 43(6):695-711, 2003). Another more extreme example is the well-known peer-to-peer distribution scheme. Here, clients jointly “host” a shared resource, for instance, a video file, and the question which of the different download sources serves the request becomes less relevant or even completely irrelevant.
What these examples have in common is that the content, or in other words the information, moves to the center stage. Driven by this trend, the networking research community has lately started investigating so-called content-centric or information-centric networks (compare V. Jacobson, M. Mosko, D. Smetters, and J. Garcia-Luna-Aceves, “Content-centric networking”, Whitepaper, Palo Alto Research Center, January 2007; PSRIP Deliverable D2.2, “Conceptual Architecture of PSIRP Including Subcomponent Descriptions”, August 2008, available online at http://psirp.org). A gist of such a concept is that information objects become the first order elements in the network, i.e. the routing layer is aware of the content that is transported. This opens the door to many optimizations not possible today, such as optimized routing or transparent caching.
The 4WARD Future Internet project (compare FP7 4WARD project homepage, http://4ward-project.eu) has even broadened the scope of information-centric networking, so that also non-dissemination traffic (such as a voice call), network services or the virtual representations of real-world objects (such as the Eiffel tower) shall be handled. Also user identities can be mapped into the NetInf (Networks of Information) namespace using the real-world object representation, so that for instance a government-issued signature card can securely be mapped into the virtual world. The corresponding concept is referred to as Networks of Information, NetInf (compare C. Dannewitz, K. Pentikousis, R. Rembarz, E. Renault, O. Strandberg and J. Ubillos, “Scenarios and research issues for a Network of Information”, In Proc. 4th Int. Mobile Multimedia Communications Conf., Oulu, Finland, July 2008; B. Ahlgren, M. D'Ambrosio, C. Dannewitz, M. Marchisio, I. Marsh, B. Ohlman, K. Pentikousis, R. Rembarz, O. Strandberg, V. Vercellone, “Design Considerations for a Network of Information”, in Proc. ReArch. 2008, Re-Architecting the Internet Workshop, Madrid, Spain, December 2008).
A gist that influences the overall architecture is the identifier/locator split. In NetInf, the functional over-loading of IP addresses or URIs acting as both identifiers and locators may be eliminated via a clean split of those two functions. Each object will have one or more locators pointing at the location of a piece of information in the network and a separate identifier, enabling the persistent identification of the object regardless of possible location changes or replication in the network. In order to make this system work, the bindings and indirections between the different objects need to be handled efficiently; this task is carried out by an NR (Name Resolver/Name Resolution) entity, also denoted as resolution node. Details about the NetInf architecture, including the naming scheme, the name resolution framework and the object model are available in C. Dannewitz, K. Pentikousis, R. Rembarz, E. Renault, O. Strandberg and J. Ubillos, “Scenarios and research issues for a Network of Information”, In Proc. 4th Int. Mobile Multimedia Communications Conf., Oulu, Finland, July 2008, and B. Ahlgren, M. D'Ambrosio, C. Dannewitz, M. Marchisio, I. Marsh, B. Ohlman, K. Pentikousis, R. Rembarz, O. Strandberg, V. Vercellone, “Design Considerations for a Network of Information”, in Proc. ReArch. 2008, Re-Architecting the Internet Workshop, Madrid, Spain, December 2008.
In the context of this application, the term “network of information” (NetInf) may hence particularly denote a communication network in which a plurality of communicatively coupled nodes are provided and which is based on an information-centric architecture in which a provisioning of information objects is possible based on an identity identifying a specific information object and based on a locator specifying a location at which the specific information object is available. Such a network of information may involve wired and/or wireless communication between the various nodes.
The term “node” may particularly denote a communication partner device which may be configured for communication with one or more other communication partner devices in a network. For instance, such a node may be a user equipment to be operated by a user and to be coupled to a communication network. Examples are mobile phones, laptops or personal computers, data cards for plugging or on-board integration into laptops or personal computers, personal digital assistants (PDAs), navigation systems, portable game consoles, etc. Hence, mobile (for example portable) or stationary communication devices can be operated in accordance with a corresponding communication architecture. For instance, such a communication device may be used in the context of telecommunications.
The term “information object” may particularly denote a set of data representing information content or use data (for instance text such as a database or a story or an article, or multimedia content such as music data, video data, or any other information related to a service or an application) which can be requested by one node and provided by another node communicatively coupled to one other node in a network of information. Such an information object may be characterized for communication purposes by an information object identity in combination with corresponding location pointing information.
The term “information object identity” may particularly denote an unambiguous (for example unique) identifier of an information object which can be used for identifying an information object during communication of different nodes of a network of information and which can be used for distinguishing between an information object and other information objects. In other words, such an information object identity may be considered as a name of a corresponding information object.
The term “location pointing information” may particularly denote a locator item (such as data block serving as an address of a node at which the corresponding information object is available) pointing at a location (such as a node capable of providing specific data) of an information object in a network of information. Such an address may be for instance an Internet Protocol (IP) address being a numerical identification (logical address) that can be assigned to devices participating in a computer network utilizing the Internet Protocol for communication between its nodes. Location pointing information may provide a link to a node at which a specific information object is available for download. In other words, such a location pointing information may be considered as an address of a corresponding information object.
The term “resolution node” may particularly denote a name resolver node in a network of information. A publishing initiation node may provide the resolution node with location pointing information regarding a corresponding information object. The latter can be provided by the publishing initiation node upon request of an information object requesting node. Hence, a resolution node may manage or handle data blocks each of which including an indication at which location or node of a network of information an information object or other piece of data is available. Such a resolution node may be configured for receiving such data blocks from a publishing initiation node offering a corresponding service and may be configured for transmitting such data blocks to an information object requesting node requesting a corresponding service.
The term “publishing initiation node” may particularly denote a node in a network of information which node which can indicate to the resolution node an information object in conjunction with an assigned locator and may therefore fore indicate which piece of information is available where in a network. The publishing initiation node may be at the same time the provider of a corresponding information object itself or may be another communication entity.
The term “information object requesting node” may particularly denote a node in a network of information which node may search for a location of a specific information object in a network of information. For this purpose, the information object requesting node may send a query to a resolution node and may ask the latter for a location of a node offering a corresponding service of providing the desired information object.
Now referring to FIG. 7, in order make an information object 708 known in a network of information 700, information object 708 has to be published. As illustrated by a dashed line in FIG. 7, publishing may be done by sending a PUBLISH message P1 to a name resolver (NR) 702 stating that the information object 708 designated by an identifier IDObj is available at a network location designated by LocObj. The abbreviation Loc denotes a locator (also called location pointing information herein). Such a locator points at a location of a data object 708 in network 700, for instance it denotes a network address, for example an IP address. In that sense, the notation “IDObj@LocObj” can be understood that an information object “Obj” with an identifier “IDObj” is available at (or can be requested via) a network of information location designated by location pointing information “LocObj”.
According to NetInf, each object 708 may have one or more locators pointing at the location of a piece of information in the network 700 and an identifier IDObj, enabling the persistent identification of the information object 708 regardless of possible location changes or replication in the network 700.
Here, LocObj, can also be a list of locations. If the information object 708 has already been published before, the additional location is added or updated in the database. If this is the first registration, a new entry is created.
Solid lines in FIG. 7 illustrate the process of retrieving a file from the NetInf network 700. As outlined above, a gist is that a user 706 requests information by its ID (Identifier), without knowing (and bothering) from which node 704 at which location it will be served. It does not matter how the ID is obtained, for instance via a link in an email or some sort of search operation.
In order to retrieve a file, what in a first step client 706 has to perform is to resolve the identifier IDObj of the information object 708 into its locator LocObj by contacting NR 702 (steps R1 and R2). In FIG. 7 this is done by a name resolution client (NRC) located on the client 706. After the location is known, the client 706 can proceed and retrieve the information object 708 from node 704, i.e. the actual storage location LocObj (steps R3 and R4).
While the former case is more likely to be used when NetInf is deployed in connection with IP, native NetInf-enabled networks also make it possible to handle the name resolution in the network, i.e. by one or more NetInf aware routers which contact the NR and request a storage location. This can for instance be realized by an NRC entity present on the first hop router and/or further routers in the network. The request can then—as in the above example—be routed to the storage location.
Once a client has retrieved a file, it can be published again, similar as in peer-to-peer networks. Optional encryption ensures that only authorized parties can access the actual data. Otherwise, the intention is to enable data to roam around freely in order to support replication, caching and other optimizations.
The fact that information objects can float around freely in the network is a central element of the information-centric paradigm. The fact that also the routing infrastructure identifies what data it is transporting is a key to the optimizations envisaged by NetInf. As the source of the download is not pre-determined in NetInf, current schemes based on securing the channel between the hosts do not apply anymore. Thus, it may be desired to secure access to the object itself.
Simple approaches might include password-based encryption or the use of pre-shared keys. This might work on the small scale, but also here the secrets (password, key) need to be distributed.
There may be a need for providing a securely operable network of information.